翻訳と辞書
Words near each other
・ Hollywood Park Racetrack
・ Hollywood Park, Texas
・ Hollywood Party
・ Hollywood Party (1934 film)
・ Hollywood Pictures
・ Hollywood Pinafore
・ Hollywood Playhouse
・ Hollywood Plaza Hotel
・ Hollywood Police Department (Florida)
・ Hollywood Post Alliance
・ Hollywood Potato Chip
・ Hollywood Premiere Theatre
・ Hollywood Presbyterian Medical Center
・ Hollywood Preview
・ Hollywood Prevue Stakes
Hollywood principle
・ Hollywood Private Hospital
・ Hollywood Professional School
・ Hollywood Rat Race
・ Hollywood Records
・ Hollywood Records discography
・ Hollywood Reel Independent Film Festival
・ Hollywood Regency
・ Hollywood Rehearsal
・ Hollywood Reservoir
・ Hollywood Residential
・ Hollywood Rip Ride Rockit
・ Hollywood Road
・ Hollywood Road Park
・ Hollywood Rock


Dictionary Lists
翻訳と辞書 辞書検索 [ 開発暫定版 ]
スポンサード リンク

Hollywood principle : ウィキペディア英語版
Hollywood principle

In computer programming, the Hollywood principle is stated as "don't call us, we'll call you." It has applications in software engineering; see also implicit invocation for a related architectural principle.
==Overview==

The Hollywood principle is a software design methodology that takes its name from the cliché response given to amateurs auditioning in Hollywood: "Don't call us, we'll call you". It is a useful paradigm that assists in the development of code with high cohesion and low coupling that is easier to debug, maintain and test.
Most beginners are first introduced to programming from a diametrically opposed viewpoint. Programs such as Hello World take control of the running environment and make calls on the underlying system to do their work. A considerable amount of successful software has been developed using the same principles, and indeed many developers need never think there is any other approach. After all, programs with linear flow are generally easy to understand.
As systems increase in complexity, the linear model becomes less maintainable. Consider for example a simple program to bounce a square around a window in your favorite operating system or window manager. The linear approach may work, up to a point. You can keep the moving and drawing code in separate procedures, but soon the logic begins to branch.
* What happens if the user resizes the window?
* Or if the square is partially off-screen?
* Are all those system calls to get such resources as device contexts and interacting with the graphical user interface really part of the solution domain?
It would be much more elegant if the programmer could concentrate on the application (in this case, updating the coordinates of the box) and leave the parts common to every application to something else.
The key to make this possible is to sacrifice the element of control. ''Instead of your program running the system, the system runs your program''. In our example, our program could register for timer events, and write a corresponding event handler that updates the coordinates. The program would include other callbacks to respond to other events, such as when the system requires part of a window to be redrawn. The system should provide suitable context information so the handler can perform the task and return. The user's program no longer includes an explicit control path, aside from initialization and registration.
Event loop programming, however, is merely the beginning of software development following the Hollywood principle. More advanced schemes such as event-driven object-orientation go further along the path, by software components sending messages to each other and reacting to the messages they receive. Each message handler merely has to perform its own local processing. It becomes very easy to unit test individual components of the system in isolation, while integration of all the components typically does not have to concern itself excessively with the dependencies between them.
Software architecture that encourages the Hollywood principle typically becomes more than "just" an API – instead, it may take on more dominant roles such as a software framework or container. Examples:
* In Windows:
*
* MFC is an example of a framework for C++ developers to interact with the Windows environment.
*
* .NET framework is touted as a framework for scalable enterprise applications.
* On the Java side:
*
* Enterprise JavaBeans (EJB) specification describes the responsibilities of an EJB container, which must support such enterprise features as remote procedure calls and transaction management.
All of these mechanisms require some cooperation from the developer. To integrate seamlessly with the framework, the developer must produce code that follows some conventions and requirements of the framework. This may be something as simple as implementing a specific interface, or, as in the case of EJB, a significant amount of wrapper code, often produced by code generation tools.

抄文引用元・出典: フリー百科事典『 ウィキペディア(Wikipedia)
ウィキペディアで「Hollywood principle」の詳細全文を読む



スポンサード リンク
翻訳と辞書 : 翻訳のためのインターネットリソース

Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.